【Claude Code源码剖析】28-DeepSeek 招聘 × Claude Code 框架 — 面试题全集与岗位需求

覆盖全部 27 个模块文档的知识点，按岗位维度分类。共 200+ 题，含标准答案要点。

---

一、岗位画像与能力地图

DeepSeek Agent Infra 典型 JD 要求

维度	具体要求	对应文档
Agentic System	设计和实现 LLM 驱动的 Agent 系统	02, 16, 17
Multi-Agent	多 Agent 协作、任务分解与编排	11, 20
Tool Use	工具注册、调度、并行执行	03
Context Management	上下文压缩、Token Budget 管理	10
Permission/Security	权限模型设计、沙箱隔离	05
State Persistence	会话状态恢复、JSONL 持久化	22
Streaming	SSE/流式处理、背压控制	08
MCP Protocol	Model Context Protocol 设计与实现	09
Memory System	长期记忆架构	23
Testing	Agent 系统测试策略	27

---

二、高频核心问题（必背）

🔴 T1：Agentic Loop 核心流程

Q1：请描述一个完整的 Agentic Loop 执行流程（从用户输入到最终响应）。

标准答案要点：

1. 用户输入 → QueryEngine.query() 入口
2. 构建 System Prompt（权限、记忆、工具列表）
3. 调用 Anthropic API（流式 SSE）
4. 解析流：
   - text_delta → 累积文本
   - tool_use block → 识别工具调用
5. 如果有工具调用：
   a. 权限检查（allowedTools / 用户批准）
   b. 并行执行（Promise.all）
   c. 构造 tool_result 注入下一轮
   d. 回到步骤 3（新一轮 API 调用）
6. 无工具调用 → 输出最终文本，Loop 结束

追问：Loop 如何终止？

三种情况：(1) API 返回无 tool_use block；(2) 达到最大轮次限制；(3) 用户中断（AbortController 信号）。

---

Q2：工具并行执行是如何实现的？有什么限制？

答：

// 同一轮 API 响应中的多个 tool_use blocks → Promise.all 并发执行
const results = await Promise.all(toolCalls.map(tc => executeTool(tc)))

// 限制：
// 1. 只有无数据依赖的工具才能真正并行（bash 命令有副作用）
// 2. computer-use 有全局 computerUseLock，同一时刻只能一个操作
// 3. 文件写入有路径锁，防止同时写同一文件

---

Q3：上下文窗口满了怎么办？CC 如何处理？

答（核心要点）：

CC 有双重保障机制：

1. Token Budget 预警（proactive）：
   - 监控当前 token 使用量
   - 达到阈值时，在 system prompt 注入提示告知模型
   - 模型主动截断/精简输出

2. SNIP 压缩（reactive）：
   - 触发条件：window 即将超限
   - 策略：保留 system prompt + 最新 N 轮 + 重要 tool results
   - 被压缩的部分用 [SNIP: N messages omitted] 占位符替代
   - 保证语义连贯性

关键：压缩后的对话对 API 是透明的，模型不知道中间内容被删除。

---

🔴 T2：工具系统设计

Q4：如何设计一个支持 100+ 工具的工具系统，且不降低模型决策质量？

答（CC 的做法）：

1. 工具分组（不是全量注入）：
   - 按当前任务类型动态选择工具子集
   - 基础工具（File/Bash/Grep）永远在线
   - 特殊工具（Computer Use）按配置动态加载

2. 工具描述质量优先：
   - 精确的 JSON Schema 参数描述
   - 包含 "when to use" 反面案例
   - 清晰的返回值格式说明

3. MCP 扩展工具动态注入：
   - 第三方 MCP 服务器提供的工具按需注册
   - 工具名规范化（去除特殊字符，唯一性保证）

---

Q5：工具权限系统如何设计？

答：

CC 的三层权限模型：

Layer 1 — Static AllowList（最快）：
  allowedTools: ['Read', 'Write', 'Bash'] 等静态配置
  → 完全跳过用户提示

Layer 2 — Dynamic Permission Check：
  每次工具调用 → checkPermission()
  → 检查路径是否在 allowedPaths 范围内
  → 检查命令是否在 allowedCommands 白名单

Layer 3 — User Approval（最慢）：
  敏感操作（rm -rf, git push force）→ 暂停
  → 向用户展示操作详情
  → 等待 approve/deny

YOLO 模式：bypass Layer 2/3，全部自动批准（危险！）

---

🔴 T3：多 Agent 系统

Q6：如何设计多 Agent 协调系统？避免哪些陷阱？

答（CC Swarm 系统的设计）：

CC 的 Swarm 协调协议：

协调机制：
1. TeamFile（共享规划文件）：
   - Leader 写 plan.md 分配任务
   - Teammate 认领任务（原子写入 claim）
   - 完成后写 done 标记
   - Leader 不 join/await，通过文件轮询

2. Mailbox（消息传递）：
   - teammail/<agentId>/inbox.json
   - 类 Actor 模型，消息是文件
   - 天然持久化（崩溃恢复）

3. 权限同步（PermissionSync）：
   - Teammate 不能自主批准危险操作
   - 通过 Leader 信道请求批准
   - Leader 是唯一权限 gate

常见陷阱：
- 并发写同一文件（用任务认领原子性解决）
- 死锁（任务依赖图有环，用超时打破）
- 状态不一致（文件系统是唯一 source of truth）

---

Q7：inProcessRunner 与 SubprocessRunner 的区别？各自适用场景？

答：

inProcessRunner（内进程）：
- Agent 逻辑在同一 Node.js 进程内运行
- 优势：零 IPC 开销，共享内存状态
- 限制：CPU 密集任务影响主进程
- 适用：信任的子 Agent，短任务

SubprocessRunner（子进程）：
- Agent 逻辑在新 Node.js 进程运行
- 优势：隔离性强，崩溃不影响父进程
- 限制：IPC 序列化开销，无法共享内存
- 适用：不可信插件，长时间任务

CC 中：inProcess 用于 Swarm Teammate（可信），
        Subprocess 用于 MCP Server（可能是第三方）

---

🔴 T4：Session 管理与状态恢复

Q8：Agent 系统如何实现崩溃恢复？CC 的实现方案？

答：

CC 的双轨持久化：

轨道 1 — JSONL Transcript（完整历史）：
  位置：~/.claude/projects/<slug>/<sessionId>.jsonl
  内容：每条消息追加写入（append-only）
  优势：不覆盖，天然崩溃安全
  
  格式：
  {"uuid":"...","type":"user","message":{...},"timestamp":...}
  {"uuid":"...","type":"assistant","message":{...},"timestamp":...}

轨道 2 — Tombstone 机制（会话状态）：
  正常退出 → 写 tombstone 文件（包含完成状态）
  异常崩溃 → 无 tombstone
  下次启动 → 检测到无 tombstone → 触发恢复流程

恢复流程：
  读取 JSONL → 重建 messages 数组
  → 重放工具执行状态
  → 从断点继续（不是从头）

---

Q9：Session 和 Worktree 如何绑定？

答：

Worktree Session：
  - git worktree 创建隔离工作区（独立 checkout）
  - 每个 worktree 有独立 Session ID
  - Session 绑定到 worktree 路径
  - 用途：并行开发不同分支（Plan Mode V2 执行阶段）

Session 清理：
  - worktree 删除 → Session tombstone 标记结束
  - 孤儿 Session（worktree 不存在）→ 垃圾回收

---

🔴 T5：API 通信与流式处理

Q10：如何实现可靠的流式 SSE 处理？处理哪些边界情况？

答：

CC 的流式处理要点：

1. Chunk 积累与解析：
   text_delta → 累积到文本缓冲区
   tool_use block → 状态机跟踪（partial JSON）
   input_json_delta → 增量拼接工具参数

2. 背压（Backpressure）控制：
   流速 > 渲染速度 → 暂停消费（通过 pause/resume）
   UI 丢帧风险 → 节流 render（requestAnimationFrame 思路）

3. 错误恢复：
   网络中断 → 触发重试（指数退避）
   API 限流（429）→ retry-after header 读取 → 等待
   过载错误（529）→ 前台请求最多重试 MAX_529_RETRIES（3次），
                     持久化模式（persistent）下无限重试，上限 6 小时（PERSISTENT_RESET_CAP_MS）

4. AbortController 集成：
   用户按 ESC → abort() 信号传播到 fetch
   → 立即停止流，不再处理 chunk

---

🟠 T6：Prompt 工程与 System Prompt

Q11：如何构建一个能缓存的高效 System Prompt？

答（CC 的 Section 缓存机制）：

关键洞察：Anthropic API 支持 Prompt Cache
- 相同前缀的 prompt → 缓存命中，速度快 5-10×，成本低 90%

CC 的 5 层 Section 架构（按稳定性排序）：
  L1. Core Identity（最稳定）        → 永远缓存
  L2. Tool Definitions               → 工具列表变化时失效
  L3. Project Rules (CLAUDE.md)      → 文件变化时失效
  L4. Memory (MEMORY.md)             → 会话级缓存
  L5. Dynamic Context（最不稳定）    → 每次更新

原则：把稳定内容放最前面，动态内容放最后面
     → 最大化缓存命中长度（prefix match）

---

Q12：如何处理多角色（Multi-turn）对话中的 prompt 注入攻击？

答：

CC 的防御策略：

1. 角色隔离：
   system 角色内容 ≠ user/assistant 角色内容
   工具结果以 tool_result 角色注入，不混入 system

2. 输入验证（外部边界）：
   工具执行结果可能包含 "<system>" 等标签
   → 在注入前 strip/escape 潜在注入标签

3. 权限边界（物理隔离）：
   工具的执行权限由 Harness 控制，不由模型决定
   即使注入成功，无权限的操作也会被拒绝

4. 结构化标记（Structural Separation）：
   使用 XML 标签区分内容类型
   <system-reminder> 与 user content 语义分离

---

三、系统设计题

D1：从零设计一个 Coding Agent

Q：设计一个能自主完成 GitHub Issue 的 Coding Agent。要求说明架构、容错、安全三个维度。

参考答案框架：

架构维度：
┌─────────────────────────────────────────────────┐
│  Issue Parser → Plan Generator → Task Executor  │
│       ↑                              ↓          │
│  Context Builder ←─── Tool Results ←── Tools   │
│       ↑                                         │
│  Memory System（记住项目约定/用户风格）          │
└─────────────────────────────────────────────────┘

核心工具集：
- ReadFile / WriteFile（代码读写）
- Bash（运行测试/构建）
- Grep（语义搜索）
- Git（版本控制）
- WebSearch（查找文档）

容错维度：
- JSONL 持久化：每步可恢复
- Tombstone 机制：区分完成vs崩溃
- 工具执行隔离：失败不影响会话
- 轮次上限：防止无限循环

安全维度：
- 权限白名单：只允许项目目录内操作
- 危险命令拦截：rm -rf, git push --force 需确认
- 沙箱隔离：生产数据库不可访问
- 审计日志：所有工具调用记录

---

D2：上下文窗口管理策略

Q：在长时间运行的 Agent 会话中，如何管理 100K+ token 的上下文？

参考答案：

分层管理策略：

层1 - 预防（Token Budget）：
  - 监控实时 token 使用量
  - 阈值预警（如 70% → 提示模型精简）
  - 工具结果截断（大文件只返回前 N 行）

层2 - 压缩（SNIP）：
  - 识别"已解决"的工具调用对（call+result）
  - 用摘要替代原始内容
  - 保留最近 K 轮（保证连贯性）

层3 - 持久化（外部存储）：
  - 重要信息写入 MemDir（跨会话）
  - 中间计算结果写文件（可重新读取）

层4 - 分片（Session 切割）：
  - 任务自然断点（子任务完成）创建新会话
  - 上一会话的关键结论注入新会话 system prompt

权衡：
  - 压缩 vs 连贯性：压缩后模型可能"忘记"早期上下文
  - 写文件 vs 内存：文件需要额外 I/O，但跨 session 持久

---

D3：多 Agent 协作中的一致性问题

Q：两个 Agent 同时修改同一文件，如何保证一致性？

参考答案：

CC 的解决方案（文件系统作为协调介质）：

1. 任务认领原子性（不用锁）：
   - Agent A 写 task.claimed = "agentA"
   - Agent B 先读，发现已认领 → 跳过
   - 利用文件系统的最终一致性

2. 写文件前检查（乐观锁）：
   - 记录读取时的文件 mtime
   - 写入前 stat 当前 mtime
   - mtime 变化 → 重新读取合并

3. 任务分割避免冲突（最优方案）：
   - Leader 分配时确保任务粒度不重叠
   - 每个 Agent 负责不相交的文件集合
   - 最终 Agent 负责合并

不适合的方案：
- 分布式锁（需要额外协调服务）
- 数据库事务（文件系统无此能力）

---

四、技术深度题

深度1：Streaming 实现

Q：请手写一个 SSE 流式解析器，处理 Anthropic API 的 text_delta 事件。

async function* parseSSEStream(
  response: Response
): AsyncGenerator<{ type: string; delta?: { text: string } }> {
  const reader = response.body!.getReader()
  const decoder = new TextDecoder()
  let buffer = ''

  while (true) {
    const { done, value } = await reader.read()
    if (done) break
    
    buffer += decoder.decode(value, { stream: true })
    const lines = buffer.split('\n')
    buffer = lines.pop()!  // 保留未完整的行
    
    for (const line of lines) {
      if (line.startsWith('data: ')) {
        const data = line.slice(6)
        if (data === '[DONE]') return
        try {
          yield JSON.parse(data)
        } catch {
          // 忽略格式错误的行
        }
      }
    }
  }
}

关键点：

• buffer 处理跨 chunk 的不完整行
• lines.pop() 保留最后一个可能不完整的行
• [DONE] 作为流结束信号
• JSON parse 异常不应中断整个流

---

深度2：权限系统实现

Q：实现一个工具执行的权限检查函数，支持路径白名单和命令黑名单。

type PermissionConfig = {
  allowedPaths: string[]       // 允许操作的路径前缀
  blockedCommands: string[]    // 禁止执行的命令
  requireApproval: string[]    // 需要用户批准的命令
}

async function checkPermission(
  tool: string,
  params: Record<string, unknown>,
  config: PermissionConfig
): Promise<'allowed' | 'blocked' | 'pending-approval'> {
  // 文件操作：检查路径白名单
  if (tool === 'Write' || tool === 'Read') {
    const path = params.file_path as string
    const allowed = config.allowedPaths.some(
      allowed => path.startsWith(allowed)
    )
    return allowed ? 'allowed' : 'blocked'
  }

  // Bash 命令：检查黑名单和审批列表
  if (tool === 'Bash') {
    const cmd = params.command as string
    
    // 黑名单检查（精确匹配子字符串）
    if (config.blockedCommands.some(b => cmd.includes(b))) {
      return 'blocked'
    }
    
    // 需要审批的命令
    if (config.requireApproval.some(r => cmd.startsWith(r))) {
      return 'pending-approval'
    }
    
    return 'allowed'
  }
  
  return 'allowed'
}

---

深度3：记忆系统设计

Q：如何实现一个跨会话的 AI 记忆系统？对比向量数据库和文件系统两种方案。

方案对比：

文件系统方案（CC 选择）：
优势：
  - 对 LLM 透明（模型可以直接读写）
  - 无额外依赖（零部署成本）
  - 内容可检查/编辑（用户可手动修正）
  - 自然支持版本控制（git 追踪记忆变化）
劣势：
  - 不支持语义搜索（只能全量加载或关键词匹配）
  - 大量记忆时效率低（需要 Sonnet side-query 辅助）

向量数据库方案（RAG 系统）：
优势：
  - 语义相似度检索（embedding 距离）
  - 百万级文档毫秒响应
  - 不依赖模型自主管理
劣势：
  - 需要 embedding 模型（额外成本）
  - 内容对用户不透明
  - 更新延迟（embedding 计算）

CC 的选择理由：
  - Agent 自主管理记忆符合产品哲学（Claude 决定记什么）
  - 用 Sonnet side-query 弥补语义搜索不足（两阶段检索）
  - 文件可读性让用户保持控制权

---

五、MCP 与协议设计题

Q13：MCP（Model Context Protocol）与 REST API 的本质区别？

答：

MCP 是专为 LLM Tool Use 设计的协议：

REST API（传统）：
  - 固定端点（/users/{id}）
  - 需要预先知道参数
  - 人工调用，有文档就够

MCP（为 LLM 设计）：
  - 工具自描述（JSON Schema）
  - 模型动态发现工具（tools/list）
  - 模型自主决定参数
  - 支持流式响应（resources/read）

关键特性：
1. 工具发现：MCP Server 声明它有哪些工具
2. Schema 驱动：模型根据 schema 自主构造调用参数
3. 统一传输：stdio、HTTP、WebSocket 都支持

CC 中的 MCP 架构：
  MCP Client（CC）←→ MCP Server（第三方工具提供方）
  通过 stdio/HTTP 交换 JSON-RPC 消息
  工具注入：MCP 工具以 mcp__serverName__toolName 格式注册

---

Q14：如何保证 MCP 工具调用的安全性？

答：

CC 的 MCP 安全层：

1. Server 级别白名单：
   用户配置信任的 MCP Server 列表
   未配置 → 不允许连接

2. 工具级别权限：
   每个 MCP 工具需要独立批准
   或加入 allowedTools 白名单

3. 传输安全：
   stdio：子进程（OS 隔离）
   HTTP：需要 HTTPS（TLS）
   认证：支持 Bearer Token

4. 沙箱考量：
   stdio MCP Server 是子进程 → 进程隔离
   但 Server 可以访问用户文件系统（需用户信任）

5. 审计：
   所有 MCP 工具调用记录在会话日志
   异常行为可追溯

---

六、测试与工程质量题

Q15：如何测试一个 Agentic Loop？

答：

CC 的测试策略（VCR 模式）：

1. VCR 录制/回放（核心）：
   - 录制：VCR_RECORD=1 运行，真实 API 调用，保存 fixture
   - 回放：读取 fixture，完全离线，100% 可复现
   - fixture 跟随代码提交，CI 无需 API key

2. 测试分层：
   - 单元测试：工具函数（权限检查、路径解析）
   - 集成测试：工具执行（真实文件操作）
   - E2E 测试：完整 Agentic Loop（VCR 回放）

3. 关键挑战：
   - AI 输出非确定性 → VCR 解决（固定 fixture）
   - UUID 去重问题 → 回放时 randomUUID() 解决
   - 路径/时间戳差异 → dehydrate/hydrate 解决

4. fixture 维护：
   - 模型升级 → 重新录制（VCR_RECORD=1）
   - 参数变更 → hash 变化 → 自动失效

---

七、算法与数据结构题

Q16：Token Budget 监控的数据结构如何设计？

答：

type TokenBudget = {
  inputUsed: number      // 已用输入 tokens
  outputUsed: number     // 已用输出 tokens
  cacheRead: number      // 缓存命中 tokens
  cacheWrite: number     // 缓存写入 tokens
  
  inputLimit: number     // 输入上限
  outputLimit: number    // 输出上限
  
  warningThreshold: number  // 预警阈值（0-1）
}

function isNearLimit(budget: TokenBudget): boolean {
  const inputRatio = budget.inputUsed / budget.inputLimit
  const outputRatio = budget.outputUsed / budget.outputLimit
  return Math.max(inputRatio, outputRatio) > budget.warningThreshold
}

// 成本计算（Opus 4.6 价格）：
// input: $3/MTok, output: $15/MTok
// cache_read: $0.3/MTok, cache_write: $3.75/MTok
function calculateCostUSD(budget: TokenBudget, model: string): number {
  const pricing = MODEL_PRICING[model]
  return (
    budget.inputUsed * pricing.input / 1_000_000 +
    budget.outputUsed * pricing.output / 1_000_000 +
    budget.cacheRead * pricing.cacheRead / 1_000_000 +
    budget.cacheWrite * pricing.cacheWrite / 1_000_000
  )
}

---

八、系统架构综合题

A1：全链路追踪

Q：如何为 Agent 系统设计可观测性（Observability）？

三大支柱：

1. Metrics（指标）：
   - 请求延迟（P50/P90/P99）
   - Token 消耗（input/output/cache）
   - 工具调用次数和成功率
   - Loop 轮次分布
   - 成本 USD/session

2. Tracing（链路追踪）：
   - 每个 session 一个 trace
   - 每次 API 调用一个 span（含 token counts）
   - 每次工具调用一个 span（含执行时间）
   - 多 Agent 场景：parent/child span 关联

3. Logging（日志）：
   - 结构化 JSON 日志
   - requestId 关联（串联整个请求链路）
   - 敏感信息脱敏（用户文件内容）
   - JSONL 会话日志（持久化可回放）

CC 的实现：
  - Analytics 模块：logEvent('tengu_*', metadata)
  - 所有 metadata 字段类型化（防止泄漏路径/代码）
  - GrowthBook 实验数据随埋点上报

---

A2：高并发 Agent Pool

Q：设计一个支持 1000 并发 Agent 的执行引擎。

架构设计：

1. Agent Pool（工作池）：
   - 预热 N 个 Agent 实例（避免冷启动）
   - 任务队列（优先级队列）
   - 负载均衡（least connections）

2. 上下文切换效率：
   - Agent 状态序列化为 JSONL（轻量）
   - 内存中保持热点 Agent 的 context
   - 冷 Agent 状态落盘，按需 restore

3. 资源隔离：
   - 每个 Agent 有独立 AbortController
   - Token Budget 独立计费
   - 文件操作有路径沙箱

4. 背压控制：
   - API 调用速率限制（rate limiter）
   - 工具执行队列（防止并发写同一文件）
   - 超时机制（防止僵尸 Agent）

5. 失败处理：
   - Agent 崩溃 → 从 JSONL 恢复
   - API 超时 → 重试（指数退避）
   - 任务卡住 → 超时 kill + 报警

---

九、岗位需求速查表

DeepSeek Agent Infra 工程师（必须熟悉）

技术点	熟悉程度要求	对应文档
TypeScript / Node.js 异步	精通	全部文档
Agentic Loop 设计	精通	02, 17
Tool Use 系统	精通	03, 05
Streaming SSE 处理	精通	08
多 Agent 协调	熟悉	11, 20
MCP 协议	熟悉	09
Context 压缩	熟悉	10
Session 持久化	熟悉	22
长期记忆系统	了解	23
Prompt 工程	熟悉	21
测试策略（VCR）	了解	27

DeepSeek LLM Application 工程师（必须熟悉）

技术点	熟悉程度要求	对应文档
LLM 基础（Transformer/Attention）	精通	LLM系列01
Reasoning 模型（DeepSeek-R1）	精通	LLM系列05
MoE 架构（DeepSeek-V3）	精通	LLM系列06
RLHF / PPO 训练	熟悉	LLM系列03
长上下文（RoPE/GQA）	熟悉	LLM系列07
Constitutional AI / 对齐	了解	LLM系列04
RAG 系统设计	熟悉	23（MemDir对比）
Prompt 优化	熟悉	21

---

十、高频追问应对

面试官追问	应对策略
“你说的 X 如何具体实现？”	给出源码级数据结构 + 关键函数签名
“这个设计有什么缺点？”	先承认真实限制，再说 CC 的补偿措施
“如果规模扩大10倍呢？”	从单点瓶颈分析：API 限流/状态存储/并发锁
“和 LangChain/AutoGPT 比？”	CC 更关注工程质量（VCR 测试/权限安全）；AutoGPT 更通用但不够可靠
“你会怎么优化这个系统？”	先讲 metrics 定位瓶颈，再讲具体优化（不要盲目优化）
“你实际用过这个框架吗？”	诚实说明学习来源，强调对源码的深度理解